3.             

3.1.             

3.2.             

3.2.1.             

3.2.2.             

3.2.3.             

3.2.4.             

3.2.5.             

3.2.6.             

1.             

2.             

3.             

3.1.             

3.2.             

3.2.1.             

3.2.2.             

3.2.3.             

3.2.4.             

3.2.5.             

3.2.6.             

3.2.7.             

3.2.8.             

3.2.9.            Manufacturer Parts

Manufacturer Parts” are parts that are manufactured by another company and that you can order and use in your own manufacturing process. Most typically, these are used to model commodity parts, such as fasteners or capacitors. Sometimes, they are also used to model assemblies that have been outsourced for manufacturing, but more typically a part object is used in that case.

To help understand the relationships among parts, BOMs, manufacturer parts and manufacturers, consider the following graphic:

The Manufacturer Part looks like this in 4G:PLM (note that this object also has a lifecycle phase defined by the administrator):

Figure 3.10: Manufacturer Part Details Window

 

The “Suppliers” tab lets you add suppliers for a manufacturer part:

Figure 3.11: Supplier Tab

A good example of this would be if you needed a resistor array that was manufactured by Texas Instruments. You would model Texas Instruments as a Manufacturer, and the resistor array itself as a Manufacturer Part. If you actually bought it from Arrow Electronics, you would model Arrow Electronics as a Supplier, and add it to the “Suppliers” tab of the manufacturer part.

Changes

Changes are objects that drive the lifecycle and revision of items. Changes are routed through workflows for approval and only come into effect if they reach an approved workflow status. There are several types of changes (note that your administrator may have created new subclasses or changed the notation in your 4G:PLM installation):

Change Type

Explanation

Engineering Change Order

Is used to create a new revision of an item. Anything on the item can be modified.

Manufacturing Change Order

Does not create a new revision of an item. Can only modify the AML list or a restricted set of attributes.

Change Request

Does not make any change to an item. If approved, it results in a change order of some type being created.

Deviation

Does not change an item; is used to record deviations from the standard in manufacturing.

Stop-Ship

Does not change an item; it used to model the emergency situation where a manufactured item’s shipping should be halted, pending further action.

 

The most powerful change is the ECO (engineering change order). The ECO example is handled here in detail, and then the differences of the other change types are highlighted briefly. The workflow process is the same for all change types, although your company may elect to define different workflows for different types.

ECO

This section describes a typical usage scenario for creating a new part and releasing it with an ECO. First, let’s suppose you have created a new part with the part number “DOCTEST”:

 

Figure 3.12.a: ECO

Since it’s a new part, you can edit the attributes as you please (if you have the appropriate permissions). As a new part, it’s lifecycle is “Preliminary” (or something similar), and the “Revision” is initially set to “0”. To release this part, you need to create an ECO. You can click on the blue “Change” text next to the “Action:” tag in the part window to create do this, or you can create a new ECO from the “New Objects” menu of 4G:PLM. If you have an existing ECO, you can drag and drop the item (part) onto the affected items tab of the change. An ECO can be used to release any number of items simultaneously. For our example, let’s suppose you clicked on the blue “Change” text. A dialog opens:

Figure 3.12.b: ECO

In the “Add to change” dialog, you can search for an existing change, or click on the “Create” button to create a new one (we’ll leave the change type drop-down as “ECO”). Let’s click on “Create”:

Figure 3.12.c: ECO

 

We’ll manually select the change number “ECO-DOCTEST”. Immediately, the ECO should be created and the affected items tab displayed. If your item is not automatically added, you can drag and drop it from the “Recent Items” pane on the left of the main 4G:PLM window:

Figure 3.12.d: ECO

Here, you can edit the attributes in the table. Some may be defined by your administrator, but important standard ones for you to fill out are:

Column

Meaning

New Rev

The new revision to take the item to

New Lifecycle Phase

The new lifecycle phase to take the item to

Effective Date

The date from which the change should become effective

 

The “ECO Detail” tab (may have a different name in your system) has a number of attributes to fill out:

Figure 3.12.e: ECO

There are two special fields that need to be set in order to begin the change process and route the ECO for approval. The first is to set the “Change Analyst”. This person is responsible for monitoring the process of the change through its workflow, tending to it if it becomes stuck (nobody approves or rejects) or moving it to the next step in the workflow if auto-promote hasn’t been activated by the administrator for the workflow. Clicking on the “Change” button next to “Change Analyst” displays a list of people to choose from (people who may act as change analyst is determined by membership in an administrator-defined group):

Figure 3.12.f: ECO

Clicking on the “Assign” button next to “Workflow” on the “ECO Detail” tab of the ECO opens a dialog where you can pick the desired workflow. The workflows available depend on what your administrator has defined. You can also set the change analyst from this dialog, or define additional people who should be notified that the ECO is being sent into a workflow:

Figure 3.12.g: ECO

Important: when you have filled out the “ECO Detail” tab, assigned the change analyst and set the workflow, don’t forget to click on the “Save” button before proceeding!

Now, if you switch to the “Workflow” tab of the ECO, you can see a graphical representation of the workflow that the ECO is about to go through:

Figure 3.12.h: ECO

Normally, you would click on “Promote” when you are ready to move the workflow to the next normal step, e.g. “Pending” to “Submit”:

Figure 3.12.h: ECO

In this dialog, you need to select an authorized approver and optionally additional observers, who should be informed of the ECO’s progress but cannot influence it directly.

Figure 3.12.i: ECO

After doing this, you can see the small red triangle is now just before the next step in the workflow, “Submit”. Note that you can always double-click on the special “Cancel” state to end a workflow, or on “Hold” to put it on hold, if the administrator has allowed these states.  If you have the appropriate permissions, you can double-click on any state to advance the change to that state directly.

In this case, we have set ourselves as approver, so the “Approve” and “Reject” buttons become active. If we approve, we see the workflow move to the next step:

Figure 3.12.j: ECO

Note also that all actions are recorded in the activity log. Now, the ECO can be moved step by step through the workflow by using a series of “Promote” and “Approve” actions. The states in this sample workflow have the following meanings:

Workflow State

State Meaning

Pending

The change has been newly created and added to a workflow, but nobody is actively working on the workflow

Submit

The change has been submitted and people involved have been notified

Review / Approval

An initial review step to approve moving the change forward

CCB

Change Control Board: stakeholders vote on whether to approve the change

Released

The change has been approved. The new revision becomes the current revision

Implemented

The change has been carried out in manufacturing

 

Every change must contain at least one released step (the details of step types and their effects may be found in the administrative documentation). In our example, let us suppose we have released the ECO:

Figure 3.12.k: ECO

If we look at the affected item, we can now see that the revision is at “A” and the lifecycle phase is at “Prototype”. The transition of the ECO to the released state caused this to happen:

Figure 3.12.l: ECO

The example workflow we have been using has an “Implemented” state. Once we move to this, the workflow is complete:

Figure 3.12.m: ECO

MCO

A manufacturing change order (MCO) functions in the same way as an engineering change order (ECO), but the revision of the affected item cannot be changed, nor can the bill of materials (BOM) be altered in any way. Moreover, attributes subject to change control (which normally includes most of them) cannot be changed except with an ECO.

The MCO is used to do one of three things:

1.         Change the lifecycle of an item

2.         Change attributes not subject to change control

3.         Modify approved manufacturer data (AML data)

Note that although there is no red-lining of a BOM with an MCO, changes to the AML data are tracked as red-lines, just as with an ECO.

The affected items tab of an MCO displays for information the item number, item description and old lifecycle. There should be a field for the new lifecycle, which is editable. No other fields are necessary for editing.

Figure 3.13: Manufacturer Change Oder

As with an ECO, an MCO applies always to the latest released revision of an affected item.

Deviation

A deviation is used to indicate some temporary change in the manufacturing of an item. Consequently, it requires two fields on the cover page:

l   “Effective from”

l   “Effective to”

Figure 3.14.a: Deviation

These are both date fields. If a deviation is valid from 05.02.2014 to 28.02.2014, then the “Effective from” field would be set to “05.02.2014” and the “Effective to” field to “28.02.2014”. No deviation can be released unless both of these fields are set.

The workflow of a deviation must contain a status of type “Released”. When this status is attained, the deviation is regarded as being in effect (if the “Effective to” date has not been exceeded). Once the “Effective to” date is exceeded, then the workflow should be advanced automatically to the next workflow state, which should be one of type “Complete”, and may bear a name such as “Expired”. It should also be possible to promote the deviation manually to the next state (as with any normal change order).

The affected items tab of a deviation should show for information the item number, description and lifecycle phase of the affected items. The revision should be selectable, but default to the current revision.

Figure 3.14.b: Deviation

 

By default, a deviation should apply to the most recently released revision of an affected item, but the user should be able to choose a different revision.

Stop-Ship

A stop-ship indicates that the affected item should no longer be shipped. This usually occurs due to some manufacturing quality problem that is discovered and must be analyzed. No alterations of the affected items are possible with a stop-ship.

When a stop-ship enters a workflow state of type “Released”, this signifies that the affected items should not be shipped. The final state in a workflow for a stop-ship should be of type “Complete”. This signifies that it is safe to ship the affected items again.

The affected items tab of a stop-ship cannot be used to change anything, so informational (read-only) fields should be shown for the item number, description and lifecycle. The revision field is selectable, but defaults to the current released revision.

Figure 3.15: Stop Ship

As with deviations, a stop-ship should apply by default to the current released revision of an affected item, but the user should be able to specify an earlier revision, if desired.

ECR

An engineering change request (ECR) is not used to change any item information; rather, it is a means for users to request that an engineering change, usually an ECO, be issued. This is useful because often the number of people with permission to create change orders is restricted, but a larger circle of people, e.g. from manufacturing, may wish to request changes.

Although it cannot change any item data, it is very similar in structure to a change order in that it goes through a workflow, must be assigned to a change analyst and has affected items. The affected items tab, however, shows only read-only fields for item number, description and lifecycle. The revision is also shown and is selectable, but defaults to the current revision.

When an ECR is released, it is the responsibility of the releaser to create an ECO manually. No automation is required for Release 1.0 of 4g:PLM.